7.0 KB · ⇊ 3 parts · ⤓ Micron 7.0 KB · ⤓ HTML 14.7 KB

top

Un server mwbwSOCKS è un particolare tipo di mwcaproxy che permette di effettuare connessioni mwcqTCP dirette (e, dalla versione 5, di veicolare traffico mwcgUDP oltre che mwcwTCP) tra computer su due mwdareti mwdqIP differenti nei casi in cui un instradamento diretto (mwdgmwdwrouting) non sia disponibile. È l'abbreviazione di "SOCKet Secure".

I punti di forza del mweqprotocollo SOCKS sono l'estrema semplicità di mwegimplementazione (sia dal mwewlato client che dal mwfalato server) e la completa indipendenza dal protocollo da veicolare attraverso di esso.

Storicamente SOCKS è stato usato come punto di contatto tra due mwfgLAN oppure tra una LAN e una mwfwWAN (come ad esempio mwgaInternet). Recentemente è più comune incontrare reti direttamente connesse ad Internet o connesse attraverso un mwgqproxy mwggHTTP.

• Versioni

• Logica di funzionamento

• Protocollo v4/4a

• Richiesta

• Risposta

• Collegamenti esterni

Attualmente esistono tre versioni del protocollo SOCKS:

• SOCKS 4, definito da NEC nel documento mwia"SOCKS: A protocol for TCP proxy across firewalls"

• mwigSocks 4a, definito da NEC nel documento mwiw"SOCKS 4A: A Simple Extension to SOCKS 4 Protocol"

• SOCKS 5, definito da IETF nella mwjqRFC mwjg1928

La logica di funzionamento di un server SOCKS è simile a quello di un proxy:

• Il client si collega al server SOCKS invece che al server di destinazione e, dopo una fase di mwkwhandshake in cui vengono negoziati versione del protocollo ed eventuale cifratura, invia una richiesta in cui specifica alcuni parametri tra cui l'indirizzo ip e la porta di destinazione;

• se per un qualsiasi motivo la richiesta non viene accettata (mancanza di autorizzazione, servizio non disponibile, parametri errati, ecc.) viene inviata al client una risposta negativa e termina la connessione;

• se la richiesta viene accettata, il server SOCKS cerca di stabilire una connessione col server di destinazione;

• se la connessione col server non può venir stabilita viene inviata al client una risposta negativa e termina la connessione;

• se la connessione col server viene stabilita con successo, il server SOCKS comincia a trasferire i dati in modo bidirezionale tra client e server; da questo punto in poi il server SOCKS ignora completamente il formato e il protocollo usati per il trasferimento dei dati;

• il servizio termina con la chiusura della connessione indifferentemente da parte del server o del client.

• VN: Numero di versione. Deve essere 0x04

• CD: Operazione. 0x01 per CONNECT, 0x02 per BIND

• DSTPORT: Porta TCP del server di destinazione in formato mwpanetwork byte order

• DSTIP: Indirizzo IP del server di destinazione in formato mwpgnetwork byte order

• USERID: Stringa contenente nome utente, non terminata da 0x00, di dimensione arbitraria

• NULL: 0x00

• VN: Numero di versione della risposta. Dovrebbe essere 0x00

• CD: Codice di risposta. Può assumere i seguenti valori:

• 0x5A (90 dec): richiesta accettata

• 0x5B (91 dec): richiesta rifiutata o fallita

• 0x5C (92 dec): richiesta rifiutata perché il server SOCKS non ha potuto connettersi al server mwsgident sul client

• 0x5D (93 dec): richiesta rifiutata perché il server ident e il client hanno riportato USERID differenti

• DSTPORT: ignorato per CONNECT

• DSTIP: ignorato per CONNECT

• citereffoldoc(EN) Denis Howe, SOCKS, in Free On-line Dictionary of Computing. Disponibile con licenza mwuqGFDL